• Questions and Answers
  • Preview Questions and Answers
  • Exam Tips
answers

CKA Simulator A Kubernetes 1.33

https://killer.sh

 

Each question needs to be solved on a specific instance other than your main candidate@terminal. You'll need to connect to the correct instance via ssh, the command is provided before each question. To connect to a different instance you always need to return first to your main terminal by running the exit command, from there you can connect to a different one.

In the real exam each question will be solved on a different instance whereas in the simulator multiple questions will be solved on same instances.

Use sudo -i to become root on any node in case necessary.

 

 

Question 1 | Contexts

 

Solve this question on: ssh cka9412

 

You're asked to extract the following information out of kubeconfig file /opt/course/1/kubeconfig on cka9412:

  1. Write all kubeconfig context names into /opt/course/1/contexts, one per line

  2. Write the name of the current context into /opt/course/1/current-context

  3. Write the client-certificate of user account-0027 base64-decoded into /opt/course/1/cert

 

Answer:

 

All that's asked for here could be extracted by manually reading the kubeconfig file. But we're going to use kubectl for it.

 

Step 1

First we get all context names:

This will result in:

We could also do extractions using jsonpath:

But it would probably be overkill for this task.

 

Step 2

Now we query the current context:

Which will result in:

 

Step 3

And finally we extract the certificate and write it base64 decoded into the required location:

Instead of using --raw to see the sensitive certificate information, we could also simply open the kubeconfig file in an editor. No matter how, we copy the whole value of client-certificate-data and base64 decode it:

Or if we like it automated:

Which will result in:

Task completed.

 

 

Question 2 | MinIO Operator, CRD Config, Helm Install

 

Solve this question on: ssh cka7968

 

Install the MinIO Operator using Helm in Namespace minio. Then configure and create the Tenant CRD:

  1. Create Namespace minio

  2. Install Helm chart minio/operator into the new Namespace. The Helm Release should be called minio-operator

  3. Update the Tenant resource in /opt/course/2/minio-tenant.yaml to include enableSFTP: true under features

  4. Create the Tenant resource from /opt/course/2/minio-tenant.yaml

     

ℹ️ It is not required for MinIO to run properly. Installing the Helm Chart and the Tenant resource as requested is enough

 

Answer:

Helm Chart: Kubernetes YAML template-files combined into a single package, Values allow customisation

Helm Release: Installed instance of a Chart

Helm Values: Allow to customise the YAML template-files in a Chart when creating a Release

Operator: Pod that communicates with the Kubernetes API and might work with CRDs

CRD: Custom Resources are extensions of the Kubernetes API

 

Step 1

First we create the requested Namespace minio:

 

Step 2

Now we install the MinIO Helm chart into it and name the release minio-operator:

Because we installed the Helm chart there are now some CRDs available:

Just like we can create a Pod, we can now create a Tenant, MinIOJob or PolicyBinding. We can also list all available fields for the Tenant CRD like this:

 

Step 3

We need to update the Yaml in the file which creates a Tenant resource:

We can see available fields for features like this:

 

Step 4

Finally we can create the Tenant resource:

In this scenario we installed an operator using Helm and created a CRD with which that operator works. This is a common pattern in Kubernetes.

 

 

Question 3 | Scale down StatefulSet

 

Solve this question on: ssh cka3962

 

There are two Pods named o3db-* in Namespace project-h800. The Project H800 management asked you to scale these down to one replica to save resources.

 

Answer:

If we check the Pods we see two replicas:

From their name it looks like these are managed by a StatefulSet. But if we're unsure we could also check for the most common resources which manage Pods:

Confirmed, we have to work with a StatefulSet. We could also look at the Pod labels to find this out:

To fulfil the task we simply run:

The Project H800 management is happy again.

 

 

Question 4 | Find Pods first to be terminated

 

Solve this question on: ssh cka2556

 

Check all available Pods in the Namespace project-c13 and find the names of those that would probably be terminated first if the nodes run out of resources (cpu or memory).

Write the Pod names into /opt/course/4/pods-terminated-first.txt.

 

Answer:

When available cpu or memory resources on the nodes reach their limit, Kubernetes will look for Pods that are using more resources than they requested. These will be the first candidates for termination. If some Pods containers have no resource requests/limits set, then by default those are considered to use more than requested. Kubernetes assigns Quality of Service classes to Pods based on the defined resources and limits.

Hence we should look for Pods without resource requests defined, we can do this with a manual approach:

Or we do something like:

We see that the Pods of Deployment c13-3cc-runner-heavy don't have any resource requests specified. Hence our answer would be:

 

Automatic way

Not necessary and probably too slow for this task, but to automate this process you could use jsonpath:

This lists all Pod names and their requests/limits, hence we see the three Pods without those defined.

Or we look for the Quality of Service classes:

Here we see three with BestEffort, which Pods get that don't have any memory or cpu limits or requests defined.

A good practice is to always set resource requests and limits. If you don't know the values your containers should have you can find this out using metric tools like Prometheus. You can also use kubectl top pod or even kubectl exec into the container and use top and similar tools.

 

 

Question 5 | Kustomize configure HPA Autoscaler

 

Solve this question on: ssh cka5774

 

Previously the application api-gateway used some external autoscaler which should now be replaced with a HorizontalPodAutoscaler (HPA). The application has been deployed to Namespaces api-gateway-staging and api-gateway-prod like this:

Using the Kustomize config at /opt/course/5/api-gateway do the following:

  1. Remove the ConfigMap horizontal-scaling-config completely

  2. Add HPA named api-gateway for the Deployment api-gateway with min 2 and max 4 replicas. It should scale at 50% average CPU utilisation

  3. In prod the HPA should have max 6 replicas

  4. Apply your changes for staging and prod so they're reflected in the cluster

 

Answer

Kustomize is a standalone tool to manage K8s Yaml files, but it also comes included with kubectl. The common idea is to have a base set of K8s Yaml and then override or extend it for different overlays, like here done for staging and prod:

 

Investigate Base

Let's investigate the base first for better understanding:

Running kubectl kustomize DIR will build the whole Yaml based on whatever is defined in the kustomization.yaml.

In the case above we did build for the base directory, which produces Yaml that is not expected to be deployed just like that. We can see for example that all resources contain namespace: NAMESPACE_REPLACE entries which won't be possible to apply because Namespace names need to be lowercase.

But for debugging it can be useful to build the base Yaml.

 

Investigate Staging

Now we look at the staging directory:

We can see that all resources now have namespace: api-gateway-staging. Also staging seems to change the ConfigMap value to horizontal-scaling: "60". And it adds the additional label env: staging to the Deployment. The rest is taken from base.

This all happens because of the kustomization.yaml:

  • The resources: section is the directory on which everything will be based on

  • The patches: section specifies Yaml files with alterations or additions applied on the base files

  • The transformers: section in this case sets the Namespace for all resources

We should be able to build and deploy the staging Yaml:

Actually we see that no changes were performed, because everything is already deployed:

 

Investigate Prod

Everything said about staging is also true about prod, there are just different values of resources changed. Hence we should also see that there are no changes to be applied:

We can see that now Namespace api-gateway-prod is being used.

And everything seems to be up to date for prod as well.

 

Step 1

We need to remove the ConfigMap from base, staging and prod because staging and prod both reference it as a patch. If we would only remove it from base we would run into an error when trying to build staging for example:

So we edit files base/api-gateway.yaml, staging/api-gateway.yaml and prod/api-gateway.yaml and remove the ConfigMap. Afterwards we should get no errors and Yaml without that ConfigMap:

 

Step 2

We're going to add the requested HPA into the base config file:

Notice that we don't specify a Namespace here as done also for the other resources. The Namespace will be set by staging and prod overlays automatically.

 

Step 3

In prod the HPA should have max replicas set to 6 so we add this to the prod patch:

With that change we should see that staging will have the HPA with maxReplicas: 4 from base, whereas prod will have maxReplicas: 6:

 

Step 4

Finally we apply the changes, first staging:

And next for prod:

We notice that the HPA was created as expected, but nothing was done with the ConfigMap that we removed from the Yaml files earlier. We need to delete the remote ConfigMaps manually, why is explained in more detail at the end of this solution.

Done!

 

Diff output after solution complete

After deleting the ConfigMaps manually we should not see any changes when running a diff. This is because the ConfigMap does not exist any longer in our Yaml and we already applied all changes. But we might see something like this:

Above we can see that we would change the replicas from 2 to 1. This is because the HPA already set the replicas to the minReplicas that we defined and it's different than the default replicas: of the Deployment:

This means each time we deploy our Kustomize built Yaml, the replicas that the HPA applied would be overwritten, which is not cool. It does not matter for the scoring of this question but to prevent this we could simply remove the replicas: setting from the Deployment in base, staging and prod.

 

Kustomize / Helm and State

We had to delete the remote ConfigMaps manually. Kustomize won't delete remote resources if they only exist remote. This is because it does not keep any state and hence doesn't know which remote resources were created by Kustomize or by anything else.

Helm will remove remote resources if they only exist remote and if they were created by Helm. It can do this because it keeps a state of all performed changes.

Both approaches have pros and cons:

  • Kustomize is less complex by not having to manage state, but might need more manual work cleaning up

  • Helm can keep better track of remote resources, but things can get complex and messy if there is a state error or mismatch. State changes (Helm actions) at the same time need to be prevented or accounted for.

 

 

Question 6 | Storage, PV, PVC, Pod volume

 

Solve this question on: ssh cka7968

 

Create a new PersistentVolume named safari-pv. It should have a capacity of 2Gi, accessMode ReadWriteOnce, hostPath /Volumes/Data and no storageClassName defined.

Next create a new PersistentVolumeClaim in Namespace project-t230 named safari-pvc . It should request 2Gi storage, accessMode ReadWriteOnce and should not define a storageClassName. The PVC should bound to the PV correctly.

Finally create a new Deployment safari in Namespace project-t230 which mounts that volume at /tmp/safari-data. The Pods of that Deployment should be of image httpd:2-alpine.

 

Answer

Find an example from https://kubernetes.io/docs and alter it:

ℹ️ Using the hostPath volume type presents many security risks, avoid if possible. Be aware that data stored in the hostPath directory will not be shared across nodes. The data available for a Pod depends on which node the Pod is scheduled.

Then create it:

Next the PersistentVolumeClaim:

Find an example from the K8s Docs and alter it:

Then create:

And check that both have the status Bound:

Next we create a Deployment and mount that volume:

Alter the yaml to mount the volume:

We can confirm it's mounting correctly:

 

 

Question 7 | Node and Pod Resource Usage

 

Solve this question on: ssh cka5774

 

The metrics-server has been installed in the cluster. Write two bash scripts which use kubectl:

  1. Script /opt/course/7/node.sh should show resource usage of nodes

  2. Script /opt/course/7/pod.sh should show resource usage of Pods and their containers

 

Answer:

The command we need to use here is top:

We see that the metrics server provides information about resource usage:

We create the first file, ensure to not use aliases but instead the full command names:

For the second file we might need to check the docs again:

With this we can finish this task:

 

 

Question 8 | Update Kubernetes Version and join cluster

 

Solve this question on: ssh cka3962

 

Your coworker notified you that node cka3962-node1 is running an older Kubernetes version and is not even part of the cluster yet.

  1. Update the node's Kubernetes to the exact version of the controlplane

  2. Add the node to the cluster using kubeadm

 

ℹ️ You can connect to the worker node using ssh cka3962-node1 from cka3962

 

 

Answer:
Update Kubernetes to controlplane version

Search in the docs for kubeadm upgrade:

The controlplane node seems to be running Kubernetes 1.33.1.

Above we can see that kubeadm is already installed in the exact needed version, otherwise we would need to install it using apt install kubeadm=1.33.1-1.1.

With the correct kubeadm version we can continue:

This is usually the proper command to upgrade a worker node. But as mentioned in the question description, this node is not yet part of the cluster. Hence there is nothing to update. We'll add the node to the cluster later using kubeadm join. For now we can continue with updating kubelet and kubectl:

Now that we're up to date with kubeadm, kubectl and kubelet we can restart the kubelet:

These errors occur because we still need to run kubeadm join to join the node into the cluster. Let's do this in the next step.

 

Add cka3962-node1 to cluster

First we log into the controlplane node and generate a new TLS bootstrap token, also printing out the join command:

We see the expiration of 23h for our token, we could adjust this by passing the ttl argument.

Next we connect again to cka3962-node1 and simply execute the join command from above:

ℹ️ If you have troubles with kubeadm join you might need to run kubeadm reset before

Finally we check the node status:

Give it a bit of time till the node is ready.

We see cka3962-node1 is now available and up to date.

 

 

Question 9 | Contact K8s Api from inside Pod

 

Solve this question on: ssh cka9412

 

There is ServiceAccount secret-reader in Namespace project-swan. Create a Pod of image nginx:1-alpine named api-contact which uses this ServiceAccount.

Exec into the Pod and use curl to manually query all Secrets from the Kubernetes Api.

Write the result into file /opt/course/9/result.json.

 

Answer:

https://kubernetes.io/docs/tasks/run-application/access-api-from-pod

You can find information in the K8s Docs by searching for "curl api" for example.

 

Create Pod which uses ServiceAccount

First we create the Pod:

Add the serviceAccountName and Namespace:

Create it:

 

Contact K8s Api from inside Pod

Once in the container we can connect to the K8s Api using curl, it's usually available via the Service named kubernetes in Namespace default. Because of K8s internal DNS resolution we can use the url kubernetes.default.

ℹ️ Otherwise we can find the K8s Api IP via environment variables inside the Pod, simply run env

So we can try to contact the K8s Api:

The first command fails because of an untrusted certificate, but we can ignore this with -k for this scenario. We explain at the end how we can add the correct certificate instead of having to use the insecure -k option.

The last command shows 403 forbidden, this is because we are not passing any authorisation information. For the K8s Api we are connecting as system:anonymous, which should not have permission to perform the query. We want to change this and connect using the Pod's ServiceAccount named secret-reader.

 

Use ServiceAccount Token to authenticate

We find the token at /var/run/secrets/kubernetes.io/serviceaccount, so we do:

Now we're able to list all Secrets as the Pod's ServiceAccount secret-reader.

For troubleshooting we could also check if the ServiceAccount is actually able to list Secrets:

 

Store result at requested location

We write the full result into /opt/course/9/result.json:

The easiest way would probably be to copy and paste the result manually. But if it's too long or not possible we could also do:

 

Connect via HTTPS with correct CA

To connect without curl -k we can specify the CertificateAuthority (CA):

 

 

Question 10 | RBAC ServiceAccount Role RoleBinding

 

Solve this question on: ssh cka3962

 

Create a new ServiceAccount processor in Namespace project-hamster. Create a Role and RoleBinding, both named processor as well. These should allow the new SA to only create Secrets and ConfigMaps in that Namespace.

 

Answer:
Let's talk a little about RBAC resources

A ClusterRole|Role defines a set of permissions and where it is available, in the whole cluster or just a single Namespace.

A ClusterRoleBinding|RoleBinding connects a set of permissions with an account and defines where it is applied, in the whole cluster or just a single Namespace.

Because of this there are 4 different RBAC combinations and 3 valid ones:

  1. Role + RoleBinding (available in single Namespace, applied in single Namespace)

  2. ClusterRole + ClusterRoleBinding (available cluster-wide, applied cluster-wide)

  3. ClusterRole + RoleBinding (available cluster-wide, applied in single Namespace)

  4. Role + ClusterRoleBinding (NOT POSSIBLE: available in single Namespace, applied cluster-wide)

To the solution

We first create the ServiceAccount:

For the Role we can first view examples:

So we execute:

Which will create a Role like:

Now we bind the Role to the ServiceAccount, and for this we can also view examples:

So we create it:

This will create a RoleBinding like:

To test our RBAC setup we can use kubectl auth can-i:

Like this:

Done.

 

 

Question 11 | DaemonSet on all Nodes

 

Solve this question on: ssh cka2556

 

Use Namespace project-tiger for the following. Create a DaemonSet named ds-important with image httpd:2-alpine and labels id=ds-important and uuid=18426a0b-5f59-4e10-923f-c0e078e82462. The Pods it creates should request 10 millicore cpu and 10 mebibyte memory. The Pods of that DaemonSet should run on all nodes, also controlplanes.

 

Answer:

As of now we aren't able to create a DaemonSet directly using kubectl, so we create a Deployment and just change it up:

Or we could search for a DaemonSet example yaml in the K8s docs and alter it to our needs.

We adjust the yaml to:

It was requested that the DaemonSet runs on all nodes, so we need to specify the toleration for this.

Let's give it a go:

Above we can see one Pod on each node, including the controlplane one.

 

 

Question 12 | Deployment on all Nodes

 

Solve this question on: ssh cka2556

 

Implement the following in Namespace project-tiger:

  • Create a Deployment named deploy-important with 3 replicas

  • The Deployment and its Pods should have label id=very-important

  • First container named container1 with image nginx:1-alpine

  • Second container named container2 with image google/pause

  • There should only ever be one Pod of that Deployment running on one worker node, use topologyKey: kubernetes.io/hostname for this

 

ℹ️ Because there are two worker nodes and the Deployment has three replicas the result should be that the third Pod won't be scheduled. In a way this scenario simulates the behaviour of a DaemonSet, but using a Deployment with a fixed number of replicas

 

 

Answer:

There are two possible ways, one using podAntiAffinity and one using topologySpreadConstraint.

 

PodAntiAffinity

The idea here is that we create a "Inter-pod anti-affinity" which allows us to say a Pod should only be scheduled on a node where another Pod of a specific label (here the same label) is not already running.

Let's begin by creating the Deployment template:

Then change the yaml to:

Specify a topologyKey, which is a pre-populated Kubernetes label, you can find this by describing a node.

 

TopologySpreadConstraints

We can achieve the same with topologySpreadConstraints. Best to try out and play with both.

 

Apply and Run

Let's run it:

Then we check the Deployment status where it shows 2/3 ready count:

And running the following we see one Pod on each worker node and one not scheduled.

If we kubectl describe the not scheduled Pod it will show us the reason didn't match pod anti-affinity rules:

Or our topologySpreadConstraints reason didn't match pod topology spread constraints:

 

 

Question 13 | Gateway Api Ingress

 

Solve this question on: ssh cka7968

 

The team from Project r500 wants to replace their Ingress (networking.k8s.io) with a Gateway Api (gateway.networking.k8s.io) solution. The old Ingress is available at /opt/course/13/ingress.yaml.

Perform the following in Namespace project-r500 and for the already existing Gateway:

  1. Create a new HTTPRoute named traffic-director which replicates the routes from the old Ingress

  2. Extend the new HTTPRoute with path /auto which redirects to mobile if the User-Agent is exactly mobile and to desktop otherwise

The existing Gateway is reachable at http://r500.gateway:30080 which means your implementation should work for these commands:

 

 

Answer:

Comparing for example the older Ingress (networking.k8s.io/v1) and newer HTTPRoute (gateway.networking.k8s.io/v1) CRDs then they look quite similar in what they offer. They have a different config structure but provide the same idea of functionality.

The magic of the Gateway Api comes more to shine because of further resources (GRPCRoute, TCPRoute) and the architecture which is designed to be more flexible and extendable. This will provide better integration into existing cloud infrastructure and providers like GCP or AWS will be able to develop their own Gateway Api implementations.

 

Investigate CRDs

It was mentioned that a Gateway already exists, let's verify this:

We can see that various CRDs from gateway.networking.k8s.io are available. In this scenario we'll only work directly with HTTPRoute which we need to create. It will reference the existing Gateway main which references the existing GatewayClass nginx:

 

Investigate URL reachability

We can already contact the Gateway like this:

We receive a 404 because no routes have been defined yet. We receive this 404 from a Nginx because the Gateway Api implementation in this scenario has been done via the Nginx Gateway Fabric. But for this scenario it wouldn't matter if another implementation (Traefik, Envoy, ...) would've been used, because all will work with the same Gateway Api CRDs.

The url r500.gateway:30080 is reachable because of a static entry in /etc/hosts which points to the only node in the cluster. And on that node, as well as on all others if there would be more, port 30080 is open because of a NodePort Service:

 

Step 1

Now we'll have a look at the provided Ingress Yaml which we need to convert:

We can see two paths /desktop and /mobile which point to the K8s Services web-desktop and web-mobile. Based on this we create a HTTPRoute which replicates the behaviour and in which we reference the existing Gateway:

After creation we can test:

This looks like what we want!

 

Step 2

Now things get more interesting and we need to add new path /auto which redirects depending on the User-Agent. The User-Agent is handled as a HTTP header and we only have to check for the exact value, hence we can extend our HTTPRoute like this:

We added two new rules, the first redirects to mobile conditionally on header value and the second redirects to desktop.

If the question text mentions something like "add one new path /auth" then this doesn't necessarily mean just one entry in the rules array, it can depend on conditions. We added at first the following rule:

Note that we use - path: and header:, not - path: and - header:. This means both path and header will be connected AND. So only if the path is /auto AND the header user-agent is mobile we route to mobile.

If we would do the following then these would be connected OR and it would be wrong for this question:

The next rule we added is the one for desktop, at the very end:

In this one we don't have to check any header value again because the question required that "otherwise" traffic should be redirected to desktop. So this acts as a "catch all" for route /auto.

We need to understand that the order of rules matters. If we would add the desktop rule before the mobile one it wouldn't work because no requests would ever reach the mobile rule.

Our solution should result in this:

Great, Gateway Api ftw!

 

 

Question 14 | Check how long certificates are valid

 

Solve this question on: ssh cka9412

 

Perform some tasks on cluster certificates:

  1. Check how long the kube-apiserver server certificate is valid using openssl or cfssl. Write the expiration date into /opt/course/14/expiration. Run the kubeadm command to list the expiration dates and confirm both methods show the same one

  2. Write the kubeadm command that would renew the kube-apiserver certificate into /opt/course/14/kubeadm-renew-certs.sh

 

Answer:

First let's find that certificate:

Next we use openssl to find out the expiration date:

There we have it, so we write it in the required location:

And we use kubeadm to get the expiration to compare:

Looking good, both are the same.

And finally we write the command that would renew the kube-apiserver certificate into the requested location:

 

 

Question 15 | NetworkPolicy

 

Solve this question on: ssh cka7968

 

There was a security incident where an intruder was able to access the whole cluster from a single hacked backend Pod.

To prevent this create a NetworkPolicy called np-backend in Namespace project-snake. It should allow the backend-* Pods only to:

  • Connect to db1-* Pods on port 1111

  • Connect to db2-* Pods on port 2222

Use the app Pod labels in your policy.

 

ℹ️ All Pods in the Namespace run plain Nginx images. This allows simple connectivity tests like: k -n project-snake exec POD_NAME -- curl POD_IP:PORT

 

ℹ️ For example, connections from backend-* Pods to vault-* Pods on port 3333 should no longer work

 

 

Answer:

First we look at the existing Pods and their labels:

We test the current connection situation and see nothing is restricted:

Now we create the NP by copying and changing an example from the K8s Docs:

The NP above has two rules with two conditions each, it can be read as:

 

Wrong example

Now let's shortly look at a wrong example:

The NP above has one rule with two conditions and two condition-entries each, it can be read as:

Using this NP it would still be possible for backend-* Pods to connect to db2-* Pods on port 1111 for example which should be forbidden.

 

Create NetworkPolicy

We create the correct NP:

And to verify:

Also helpful to use kubectl describe on the NP to see how K8s has interpreted the policy.

 

 

Question 16 | Update CoreDNS Configuration

 

Solve this question on: ssh cka5774

 

The CoreDNS configuration in the cluster needs to be updated:

  1. Make a backup of the existing configuration Yaml and store it at /opt/course/16/coredns_backup.yaml. You should be able to fast recover from the backup

  2. Update the CoreDNS configuration in the cluster so that DNS resolution for SERVICE.NAMESPACE.custom-domain will work exactly like and in addition to SERVICE.NAMESPACE.cluster.local

Test your configuration for example from a Pod with busybox:1 image. These commands should result in an IP address:

 

Answer:

We have a look at the CoreDNS Pods:

It looks like CoreDNS is running as a Deployment with two replicas.

 

Step 1

CoreDNS uses a ConfigMap by default when installed via Kubeadm. Creating a backup is always a good idea before performing sensitive changes:

The current configuration looks like this:

 

Step 2

We update the config:

Note that we added custom-domain in the same line where cluster.local is already defined.

Now we need to restart the Deployment:

We should see both Pods restarted and running without errors, this is only the case if there are no syntax errors in the CoreDNS config.

To test the updated configuration we create a Pod, image busybox:1 contains nslookup already:

We see that now kubernetes.default.svc.custom-domain and kubernetes.default.svc.cluster.local resolve to IP address 10.96.0.1. Which is the Kubernetes Service in the default Namespace:

This Service is often used from Pods that need to communicate with the K8s Api, like operators.

 

Recover from backup

If we messed something up we could do:

But this only works if a backup is available!

 

 

Question 17 | Find Container of Pod and check info

 

Solve this question on: ssh cka2556

 

In Namespace project-tiger create a Pod named tigers-reunite of image httpd:2-alpine with labels pod=container and container=pod. Find out on which node the Pod is scheduled. Ssh into that node and find the containerd container belonging to that Pod.

Using command crictl:

  1. Write the ID of the container and the info.runtimeType into /opt/course/17/pod-container.txt

  2. Write the logs of the container into /opt/course/17/pod-container.log

 

ℹ️ You can connect to a worker node using ssh cka2556-node1 or ssh cka2556-node2 from cka2556

 

Answer:

ℹ️ In this environment crictl can be used for container management. In the real exam this could also be docker. Both commands can be used with the same arguments.

 

First we create the Pod:

Next we find out the node it's scheduled on:

Here it's cka2556-node1 so we ssh into that node and and check the container info:

 

Step 1

Having the container we can crictl inspect it for the runtimeType:

Now we create the requested file on cka2556:

 

Step 2

Finally we query the container logs:

Here we run crictl logs on the worker node and copy the content manually, that works if it's not a lot of logs. Otherwise we could write the logs into a file on cka2556-node1 and download the file via scp from cka2556.

The file should look like this:

 

 

 

 

 

 

 

preview

CKA Simulator Preview Kubernetes 1.33

https://killer.sh

 

This is a preview of the CKA Simulator content. The full CKA Simulator is available in two versions: A and B. Each version contains at least 17 different questions. These preview questions are in addition to the provided ones and can also be solved in the interactive environment.

 

 

Preview Question 1 | ETCD Information

 

Solve this question on: ssh cka9412

 

The cluster admin asked you to find out the following information about etcd running on cka9412:

  • Server private key location

  • Server certificate expiration date

  • Is client certificate authentication enabled

Write these information into /opt/course/p1/etcd-info.txt

 

Answer:
Find out etcd information

Let's check the nodes:

First we check how etcd is setup in this cluster:

We see it's running as a Pod, more specific a static Pod. So we check for the default kubelet directory for static manifests:

So we look at the yaml and the parameters with which etcd is started:

We see that client authentication is enabled and also the requested path to the server private key, now let's find out the expiration of the server certificate:

There we have it. Let's write the information into the requested file:

 

 

Preview Question 2 | Kube-Proxy iptables

 

Solve this question on: ssh cka2556

 

You're asked to confirm that kube-proxy is running correctly. For this perform the following in Namespace project-hamster:

  1. Create Pod p2-pod with image nginx:1-alpine

  2. Create Service p2-service which exposes the Pod internally in the cluster on port 3000->80

  3. Write the iptables rules of node cka2556 belonging the created Service p2-service into file /opt/course/p2/iptables.txt

  4. Delete the Service and confirm that the iptables rules are gone again

 

Answer:

 

Step 1: Create the Pod

First we create the Pod:

 

Step 2: Create the Service

Next we create the Service:

We should see that Pods and Services are connected, hence the Service should have Endpoints.

 

(Optional) Confirm kube-proxy is running and is using iptables

The idea here is to find the kube-proxy container and check its logs:

This could be repeated on each controlplane and worker node where the result should be the same.

 

Step 3: Check kube-proxy is creating iptables rules

Now we check the iptables rules on every node first manually:

Great. Now let's write these logs into the requested file:

 

Delete the Service and confirm iptables rules are gone

Delete the Service and confirm the iptables rules are gone::

Kubernetes Services are implemented using iptables rules (with default config) on all nodes. Every time a Service has been altered, created, deleted or Endpoints of a Service have changed, the kube-apiserver contacts every node's kube-proxy to update the iptables rules according to the current state.

 

 

Preview Question 3 | Change Service CIDR

 

Solve this question on: ssh cka9412

 

  1. Create a Pod named check-ip in Namespace default using image httpd:2-alpine

  2. Expose it on port 80 as a ClusterIP Service named check-ip-service. Remember/output the IP of that Service

  3. Change the Service CIDR to 11.96.0.0/12 for the cluster

  4. Create a second Service named check-ip-service2 pointing to the same Pod

 

ℹ️ The second Service should get an IP address from the new CIDR range

 

 

Answer:

Let's create the Pod and expose it:

And check the Service IP:

Now we change the Service CIDR in the kube-apiserver manifest:

We wait for the kube-apiserver to be restarted, which can take a minute:

Now we do the same for the controller manager:

We wait for the kube-controller-manager to be restarted, which can take a minute:

Checking our Service again:

Nothing changed so far. Now we create the second Service:

And check again:

There we go, the new Service got an IP of the updated range assigned. We also see that both Services have our Pod as endpoint.

 

tips

CKA Tips Kubernetes 1.33

In this section we'll provide some tips on how to handle the CKA exam and browser terminal.

 

Knowledge

Study all topics as proposed in the curriculum until you feel comfortable with all.

 

General

  • Study all topics as proposed in the curriculum until you feel comfortable with all

  • Do 1 or 2 test sessions with this CKA Simulator. Understand the solutions and maybe try out other ways to achieve the same thing.

  • Setup your aliases, be fast and breathe kubectl

  • The majority of tasks in the CKA will also be around creating Kubernetes resources, like it's tested in the CKAD. So preparing a bit for the CKAD can't hurt.

  • Learn and Study the in-browser scenarios on https://killercoda.com/killer-shell-cka (and maybe for CKAD https://killercoda.com/killer-shell-ckad)

  • Imagine and create your own scenarios to solve

 

Components

  • Understanding Kubernetes components and being able to fix and investigate clusters: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-cluster

  • Know advanced scheduling: https://kubernetes.io/docs/concepts/scheduling/kube-scheduler

  • When you have to fix a component (like kubelet) in one cluster, just check how it's setup on another node in the same or even another cluster. You can copy config files over etc

  • If you like you can look at Kubernetes The Hard Way once. But it's NOT necessary to do, the CKA is not that complex. But KTHW helps understanding the concepts

  • You should install your own cluster using kubeadm (one controlplane, one worker) in a VM or using a cloud provider and investigate the components

  • Know how to use Kubeadm to for example add nodes to a cluster

  • Know how to create an Ingress resources

  • Know how to snapshot/restore ETCD from another machine

 

 

CKA Exam Info

Read the Curriculum

https://github.com/cncf/curriculum

Read the Handbook

https://docs.linuxfoundation.org/tc-docs/certification/lf-handbook2

Read the important tips

https://docs.linuxfoundation.org/tc-docs/certification/tips-cka-and-ckad

Read the FAQ

https://docs.linuxfoundation.org/tc-docs/certification/faq-cka-ckad

 

Kubernetes documentation

Get familiar with the Kubernetes documentation and be able to use the search. Allowed resources are:

ℹ️ Verify the list here

 

The Exam UI / Remote Desktop

The real exam, as well as the simulator, provides a Remote Desktop (XFCE) on Ubuntu/Debian. Coming from OSX/Windows there will be changes in copy&paste for example.

Official Information

ExamUI: Performance Based Exams

Lagging

There could be some lagging, definitely make sure you are using a good internet connection because your webcam and screen are transferring all the time.

Kubectl autocompletion and commands

The following are installed or pre-configured, verify the list here:

  • kubectl with k alias and Bash autocompletion

  • yq or YAML processing

  • curl and wget for testing web services

  • man and man pages for further documentation

ℹ️ You're allowed to install tools, like tmux for terminal multiplexing or jq for JSON processing

Copy & Paste

Copy and pasting will work like normal in a Linux Environment:

What always works: copy+paste using right mouse context menu What works in Terminal: Ctrl+Shift+c and Ctrl+Shift+v What works in other apps like Firefox: Ctrl+c and Ctrl+v

Score

There are 15-20 questions in the exam. Your results will be automatically checked according to the handbook. If you don't agree with the results you can request a review by contacting the Linux Foundation Support.

Notepad & Flagging Questions

You can flag questions to return to later. This is just a marker for yourself and won't affect scoring. You also have access to a simple notepad in the browser which can be used to store any kind of plain text. It might make sense to use this and write down additional information about flagged questions. Instead of using the notepad you could also open Mousepad (XFCE application inside the Remote Desktop) or create a file with Vim.

VSCodium

You can use VSCodium to edit files and you can also use its terminal to run commands. You're not allowed to install any VSCodium extensions.

Servers

Each question needs to be solved on a specific instance other than your main terminal. You'll need to connect to the correct instance via ssh, the command is provided before each question.

 

PSI Bridge

Starting with PSI Bridge:

  • The exam will now be taken using the PSI Secure Browser, which can be downloaded using the newest versions of Microsoft Edge, Safari, Chrome, or Firefox

  • Multiple monitors will no longer be permitted

  • Use of personal bookmarks will no longer be permitted

The new ExamUI includes improved features such as:

  • A remote desktop configured with the tools and software needed to complete the tasks

  • A timer that displays the actual time remaining (in minutes) and provides an alert with 30, 15, or 5 minute remaining

  • The content panel remains the same (presented on the Left Hand Side of the ExamUI)

Read more here.

 

Terminal Handling

 

Bash Aliases

In the real exam, each question has to be solved on a different instance to which you connect via ssh. This means it's not advised to configure bash aliases because they wouldn't be available on the instances accessed by ssh.

 

Be fast

Use the history command to reuse already entered commands or use even faster history search through Ctrl +r .

If a command takes some time to execute, like sometimes kubectl delete pod x. You can put a task in the background using Ctrl +z and pull it back into foreground running command fg.

You can delete pods fast with:

 

Vim

Be great with vim.

Settings

In case you face a situation where vim is not configured properly and you face for example issues with pasting copied content you should be able to configure via ~/.vimrc or by entering manually in vim settings mode:

The expandtab option makes sure to use spaces for tabs.

Note that changes in ~/.vimrc will not be transferred when connecting to other instances via ssh.

Toggle vim line numbers

When in vim you can press Esc and type :set number or :set nonumber followed by Enter to toggle line numbers. This can be useful when finding syntax errors based on line - but can be bad when wanting to mark&copy by mouse. You can also just jump to a line number with Esc :22 + Enter.

Copy&Paste

Get used to copy/paste/cut with vim:

Indent multiple lines

To indent multiple lines press Esc and type :set shiftwidth=2. First mark multiple lines using Shift v and the up/down keys. Then to indent the marked lines press > or <. You can then press . to repeat the action.